Skip to content

Conversation

@nan-li
Copy link
Contributor

@nan-li nan-li commented Nov 20, 2025

Description

One Line Summary

Add basic infrastructure to test the OneSignalInAppMessages module.

Details

  • We want to test the Objective-C framework OneSignalInAppMessages using Swift language. Previously we could access all APIs by importing directly in Objective-C. However, there are limitations to accessing internal Objective-C APIs from Swift - that is, they must all be public.
  • This is not an issue if Swift test code was accessing Swift internal methods, as it is easy to annotate @testable import in that scenario.
  • Considered making some internal APIs public, but as I added more necessary steps to tests, I found I had to expose an increasing number of internal APIs. This is not preferable.
  • While not ideal to add more Objective-C code in tests, I resorted to keeping internal APIs as is, and adding Objective-C helpers. Eventually, I expect the SDK to migrate to Swift and this would not be needed then.

Motivation

Increase tests, porting over tests.

Scope

Testing only, not changing the shipped SDK, or making any internal APIs public.

Testing

Unit testing

  • Add Swift lang test file IAMIntegrationTests and write one integration test
    • In attempt to migrate existing testDisablingIAMs_stillCreatesMessageQueue_butPreventsMessageDisplay to new tests, but behavior has changed. It becomes testPausingIAMs_doesNotCreateMessageQueue.
  • Add new module OneSignalInAppMessagesMocks for re-usable test helpers and mock functionality
  • Make a MockMessagingController in Objective C to allow us to access internal APIs on the OSMessagingController without needing to make them public. This is needed because Swift code cannot access Objective-C APIs unless they are public. This is a workaround for this limitation.
  • Add ConsistencyManagerTestHelpers with methods for repeating functionality

Manual testing

  • Just the app builds and runs still.

Affected code checklist

  • Notifications
    • Display
    • Open
    • Push Processing
    • Confirm Deliveries
  • Outcomes
  • Sessions
  • In-App Messaging
  • REST API requests
  • Public API changes
  • Tests

Checklist

Overview

  • I have filled out all REQUIRED sections above
  • PR does one thing
  • Any Public API changes are explained in the PR details and conform to existing APIs

Testing

  • I have included test coverage for these changes, or explained why they are not needed
  • All automated tests pass, or I explained why that is not possible
  • I have personally tested this on my device, or explained why that is not possible

Final pass

  • Code is as readable as possible.
  • I have reviewed this PR myself, ensuring it meets each checklist item

This change is Reviewable

@nan-li nan-li added the WIP Work In Progress label Nov 20, 2025
@nan-li nan-li force-pushed the ci/add_code_coverage branch from a69c00c to f828623 Compare November 20, 2025 20:50
Add Swift `IAMIntegrationTests` test file and check for accessibility of `OSMessagingController` from the test file
@nan-li nan-li force-pushed the tests/add_iam_tests branch 2 times, most recently from d38abc1 to 72510a5 Compare November 20, 2025 20:51
* Aren't called by anything so no need to be on the interface, these are called by the class itself.
* Without a description, the object will return something like `<OSRequestGetInAppMessages: 0x600001798bc0>`. By adding a predictable description, we can operate on the object.
* Re-usable test helpers and mock functionality
* Include own swiftlint file
* ❗️ After `OneSignalInAppMessagesMocks` was created, I had to then manually "convert to group" or else the CI had build errors about the following:

xcodebuild: error: Unable to read project 'OneSignal.xcodeproj'
Reason: The project ‘OneSignal’ is damaged and cannot be opened. Examine the project file for invalid edits or unresolved source control conflicts.
Exception: didn't find classname for 'isa' key
* Make a `MockMessagingController` in Objective C to allow us to access internal APIs on the OSMessagingController without needing to make them public. This is needed because Swift code cannot access Objective-C APIs unless they are public. This is a workaround for this limitation.
…alInAppMessages

* This extension on `UIApplication` is only used in the `OneSignalInAppMessages` framework, so there is no need to keep it in the umbrella `OneSignalFramework` framework, which causes errors if only `OneSignalInAppMessages` is tested (without also importing OneSignalFramework).
* Has helper methods for repeating functionality
* Attempt to migrate `testDisablingIAMs_stillCreatesMessageQueue_butPreventsMessageDisplay` to new tests, but behavior has changed.
* It becomes `testPausingIAMs_doesNotCreateMessageQueue`
Update IAMTestHelpers.swift
@nan-li nan-li force-pushed the tests/add_iam_tests branch from 72510a5 to 1dee76e Compare November 21, 2025 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

WIP Work In Progress

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants